組織開発の意思決定透明化のために ODDR を試すことにしました

こんにちわ。てぃーびーです。

最近システム開発界隈でたまに話題をみかける「ADR」。 ADR は Architectural Decision Records の略で、アーキテクチャーの意思決定を決まったフォーマットで記録し続ける手法です。アーキテクチャーの意思決定後、時間の経過とともに当時のアーキテクチャーを設計した人が異動や退職で不在になり、後任が現在の設計を検討する上で、なぜ現状のアーキテクチャーになっているか確認したい、といったときがこの記録が活用される典型的なケースです。それ以外にも人の記憶は不確かなため、意思決定をした本人にとっても記録は便利です。

そういった必要性に関して niku さんの以下の記事が参考になります。

2020-05-19 ADR(Architectural Decision Records)を書くと決めた理由を自分の言葉で書き出した｜ヽ（´・肉・｀）ノ｜note

私は、現在 Employee Experience を向上させることがミッションのチームにいます。前職から人事として評価制度など組織開発に関わり、似たようなお仕事をしている方と情報交換をするなかでよく耳にするのが

人事、組織に関わる意思決定は、決定した結果だけが共有されると Why や決定プロセスが見えなくなる。その結果、現場のみなさんからのあらぬ憶測を元にした不満が発生しやすい

という点です。組織開発という特性上、100%すべての情報を毎回共有できるわけではありませんが、エンジニアリング統括室では可能な範囲において最大限情報を透明化していきたい、と考えています。そこで、 ADR の考え方をベースに Organization Development Decision Records(以降 ODDR)として、組織施策の意思決定を記録し、社内の関係者に公開することで上記の懸念の解消ができると考えました。なお、もともとの ADR が持つ恩恵の部分もメリットとしてカウントしています。

ちなみに私達は開発関係者向けの組織開発として特に従業員体験の向上に関わる施策を担当するチームですが、チームメンバーは全員開発のバックグラウンドを持っています。開発分野のノウハウを組織開発にも積極的に活かす、ということをチームの Value の一つにしています。 それに加えてクラスメソッドには CLP というカルチャーがあり、その中に「やってみる - Start Small -」という項目があります。まずはやってみて、改善を繰り返せばよいという精神です。ということで、色んなことを加味して ODDR を試してみる、という意思決定に至りました。

運用方法

記録基準

意思決定の記録は以下のタイミングで実施します。

• 施策の初期導入時
• 施策の運用ルールや実際内容が変わる時
• 施策の廃止時

記録ツール

エンジニアリング統括室のタスク、情報は Notion に集約しているため、 ODDR も Notion に保存します。このあとに紹介するテンプレート、具体例では便宜上 Markdown で例示していますが、実際は Notion のテンプレートにしてあります。

テンプレート

まずは以下のようなテンプレートで運用を開始します。

具体例 - スクラムの活用

エンジニアリング統括室では、組織開発の業務にスクラムを取り入れはじめました。 そこで、スクラムの活用を Decision Records として残してみます。

まとめ

まずはお試しでスタートした ODDR 。しばらくしたら実際の施策に関わるログもたまり、恩恵の有無がみえてくると思います。 数カ月後に改めて発信できればと思います。

関連資料

• Architectural Decision Records | adr.github.io